Fritz: All Fritz/All Fritz.zip/All Fritz/FILES/MISCEOUS/YRCAL17T.LZH/YEARCAL.DOC

Text File | 1989-10-01 | 25KB | 471 lines

/***************************************************************/
        YEARCAL v0.17T 30 Sep 1989

    Copyright 1987, 1988, 1989 by Paul M. Sittler

YEARCAL makes calendars (A) and schedules (M/W/D) for years after 1582.

At the user's option, Normal, Fiscal Year, AGGIE, or 3-Digit Julian
Date Calendars can be produced, in multiple copies, for a number of
consecutive years, or both.  Fiscal Year calendars may be produced for
any arbitrary 12 or 13 month fiscal year.  The user may select a
Programmer's calendar, numbered in Hexadecimal or Octal numbers rather
than decimal numbers, and may choose one of several languages.

The calendars may be displayed on the screen, printed, or written to
a file as desired.  If written to disk, files are named like YYYY.ENG
(Normal ENGlish), YYYYFY.DUT (Fiscal-Year DUTch), YYYYAGG.TEX (Aggie-
type TEXan), or YYYYJUL.POL (3-Digit Julian Date POLish) calendars,
etc.  Hex or Octal calendar files will have an "H" or "O" added to
their names, such as YYYYH.SPA, YYYYFYO.SER or YYYYAGGH.FRE.

YEARCAL may be freely distributed, and used for non-commercial
purposes, as long as the unmodified program source code and
documentation files are distributed with it.

/***************************************************************/

A Not-so Brief History:  Why (and much of How) YEARCAL came to be. . .

In 1987, a fellow at the office asked if I could get him a calendar
for 1989, as his desk calendar only went to 1988.  I grabbed a
program that I had lying around, and did it.  I also logged on to
GENie and found a program there that did the same job.  Both of
these programs were written in BASIC, and, when interpreted, ran
slowly.  When compiled, they grew to 45-50 Kbytes or so.  I
thought I might be able to make one a little smaller, faster,
and with a few more useful features.

Along the way, I discovered that 2000 will really be a leap
year, while 1900 was not, and 2100 will not be.  To simplify
things, Best Beloved, just remember that years marking the
century will not be leap years unless evenly divisible
by 400.

The year 4000 may be peculiar as well.  The current calendar year is
actually about 26.3 seconds longer than the solar year, which means
that by 4316 the calendar will be one ady ahead of the sun.  Some
sort of correction obviously MUST be made.

I also remembered a way of making an AGGIE calendar that
has the information arranged a little differently, and added
that capability to it as well.  I decided that one might logically
desire to view a calendar on a screen, print a calendar on a
printer, or write the calendar to a file.  I thought it desirable
to make runs of multiple years or copies, so YEARCAL can do both.

Chris Lang then suggested that it would be useful to have a
program that produced fiscal year calendars.  YEARCAL will now
produce fiscal year calendars for any arbitrary 12 full-month
fiscal year.  Rich Hedges suggested that it would really be neat
to produce a fiscal year calendar for a fiscal year that begins
on a weird date, like July 15th. . .  Well, not yet, and maybe
never. . .

Turned out that adding code to accommodate 13 month arbitrary
starting dates was not all that difficult. . .  So now it does
that as well.

Then, Dale Schafer pointed out that on his IBM token ring
network setup, a banner and a blank page were being printed
between each successive calendar.  This was because I was
skillfully closing the file (PRN, CON, etc.) after every
calendar was written.  Hmmmm. . .  Also fairly easy to fix,
but required a little bit of rethinking.

I confess.  There was an undocumented feature in version 0.01c
or 0.01d that allowed the "JANUARY" month of a fiscal year to be
printed as "SUNDAY", and then "FEBRUARY" as "TUESDAY".  Further,
Not everyone has or uses DeSmet C. . .  I converted YEARCAL to
Borland's Turbo-C, and that wee beastie has been put to bed.
Damn those entomological cybernoids!!

I also received a message on my BBS that I had cleverly mis-spelled
the 1st month in Finnish.  I grabbed the old Berlitz European
Phrase Book, and verified that PRPRNUU really should have been
TAMMIKUU.  Retrospectively, I cannot imagine how that particular
error came into existence.  I sort of rule out a typo, as the two
spellings are too dissimilar.  Maybe it was an hallucination
caused by excessive blood caffiene levels. . .  As penance, I
shall listen to 'Finlandia' three times 'ere I sleep.

Forgive me, Finland, for I have sinned. . .

Another programmer, using YEARCAL to validate his own calendar
routines (7 May 1989), showed me that YEARCAL (v0.12T and before)
had been calculating the transition from 2000 to 2001 incorrectly.
I have therefor implemented Zeller's Congruence to correct this
embarassing error.  I apoligise for any inconvenience that this
error on my part may have caused.  A side effect is that YEARCAL
should now produce reasonably accurate calendars for the years
of 1582 to 4000 AD.  I was going to print annual calendars for
all of those dates and manually check them, but I ran out of paper,
toner, and time.

I started receiving messages on my bulletin board asking when I
was ever going to fix the bug that caused YEARCAL to always
crash when <V>iewing or <P>rinting the <M>onthly schedules.
This puzzled me somewhat, so I responded by requesting more
input as far as a usable bug report.  Turns out that YEARCAL
v0.10T - v0.15T did indeed crash if run from the menu of a
menuing package called HDM-IV.  (I guess some people actually
use those DOS-Shell things. . .)  I had several older versions of
HDM around, and it did NOT exhibit problems with them.  To
compound the confusion, if HDM-IV were run, followed by LOTUS-123,
YEARCAL would work properly.  Close inspection of the source code
(My Ghad!!  I wrote that crap!!  Horrors!)  uncovered an
unterminated string that was subsequently copied to another
string. . .  Since it didn't know where to stop, it copied
everything from that point in available memory until it found a
NULL.  Put simply, it was looking for nothing until it finally
found it.  My fault, clearly.  Hats off to Gerald Fieser, of
Des Moines, Iowa.  Gerald, this bug's for you!!  <29 Sep 1989>

Since Gerald caused me to scrutinise the schedule printer routines,
in a wild burst of creative effort, I added some support for the
infamous IBM line drawing characters.  If your printer (and screen)
can handle them, you may now use them.  For those of you whose
printers cannot handle them, you may still revert to using vanilla
ASCII characters as separators in the schedules.  <30 Sep 1989)

A super-serious individual (who shall remain nameless) asked me
what the AGGIE calendar was good for.  I have been using it for
some time time to keep up with meeting dates that occur more or
less by formula.  You know, such things as "First Tuesday of
every month at 7:30 pm" and the like.  No sense of humour. . .

Then, one night an old CP/M-hacking KayPro user (Don Buzzingham)
happened by, and after one too many cups of coffee, we were
inspired to do a "Programmer's" calendar.  Where is it written
that a calendar must represent the dates with decimal numbers?
Why not Hexadecimal, or (for us real fossils) Octal? Why not
Binary?  (Answer: binary representations won't fit easily and
neatly on the screen. . .  )  Why not any arbitrary number
base?  (Gag me with a spoon, Adolph!)  (Answer: unless the number
base is larger than base 4, the dates won't fit nicely either.)
In keeping with the concept of following the path of least
resistance, I took the easy way out, and added the capability of
doing Hex and Octal calendars too.

Why not have it produce calendars in a number of different
languages?  (Do you know how many languages exist?)  So, language
support for sixteen different languages was added.  This
created some problems with the limitations of the IBM(tm)
character set that came stock with my computer.  Not all of the
requisite special characters are there.  When I used the cute
special characters, and sent them to several different printers,
each printer decided to react to them in different ways, and
usually NOT by printing the special character I had intended.
Alas, proper use of the international characters is not to be,
at least not yet. . .  I apologise in advance to all of those
who care, and ask your indulgence.  I did try. . .  At the
behest of several, I have added an optional pause at the end
of each printed page, for those who wish to print out multiple
calendars on single sheets using a daisy wheel printer that
has neither forms tractor nor sheet feeder.  If you need it,
it's there now.  If you don't need it, I don't think that it
will get in the way too much. . .

I dropped Greek and Russian because of the character set
problem, and have made no attempt at adding any oriental
languages for the same reason.  (I have been tempted to add
Korean, using the McKune-Reischauer Romanisation scheme.  Let me
know if anyone cares.)  Added Afrikaans at the suggestion of a
friend. . .  Finally did add Korean (Romanised). . .
Thanx to the mostly Reverend Daniel Marek, Pastor of the Caldwell
Brethren Church, Caldwell, Texas, through the instrument of one
Briggs Myrick (hacker friend and part time philosopher), we have
now added Czech to our repertoire of voices!!

Language support for Cantonese, Gaelic, Irish, Japanese, and Turkish
was added after finding some little dictionaries in a bookstore.
I apologise in advance for the bizarre ways that I may have butchered
any particular language, and await corrections on same.

I will gladly add any language that can be represented in a standard
fashion by the Roman character set.  One fellow is supposedly trying
to get Roumanian, and we may be able to produce the first automated
calendars ever in a language used by an American Indian Tribe, if
they decide to use the roman alphabet rather than rolling their own.
The information that I need is simple:  the names of the days of the
week and the names of the months.  I suspect that there is a standard
technique for romanising Japanese, Thai, and Vietnamese, at least.

I have added Romanian now, thanks to the help of Daniel Rusu of
Los Angeles, CA, and Howard Gerber, of Houston, TX. <03/30/89>

I should like to add Thai, Vietnamese, Tagalog, Pilipino, Hawaiian,
Aleut, Crow, Mauri, Sanskrit, Farsi, and any others that YOU might
think of.

As part of my individual attempt at glasnost, I am amenable to
adding a (romanized) Russian.  I am prepared to deal with the
perestroika that such an addition would require.  (This has now
been done, with my thanks to Mikhail Gorbachev, who shall remain
nameless.)

I made the mistake of wandering into a second hand book store.
Waiting for me on a shelf was a book named "The Concise Dictionary
of Twenty-Six Languages in Simultaneous Translations" compiled by
Peter M. Bergman, 1968, Bergman Publishers.  It enabled me to add
another 9 languages.  They are:  Arabic, Esperanto, Greek, Hungarian,
Hebrew, Indonesian, Russian, Swahili, & Yiddish.  In the case of the
non-roman languages, (Arabic, Greek, Hebrew, Russian, and Yiddish),
the author did a Romanisation scheme that is more or less phonetic.
(11 May 1989)

Please note that I do NOT suggest that the Hebrew or Yiddish versions
represent a Jewish calendar, nor do I suggest that the Arabic version
will produce an Islamic calendar.  They DO NOT.

I woke up late one night with a memory of another calendar
hassle that I had experienced while in the forced employ of the
Army.  The DOD and GAO find it useful to think of dates as mere
numbers.  The so-called Julian-Date scheme is used there.  It
basically takes note of the fact that there are either 365 or
366 days in the Gregorian calendar year, and numbers a date by
its relative position in the year.  Thus, January 1 would be
001, and December 31st might be either 365 or 366.  This is
referred to as a 3-digit Julian Date, and is mighty useful if
you know what year it is.  It makes it really simple to find out
how many days there are between dates, so you can find out how
long your most important requisition has been backordered (also
known as "Lost in the System").  For greater specificity, the
Four-Digit, Five-Digit, Six-Digit, and Seven-Digit Julian Dates
can be made by adding more or less of the year in front of the
date.  February 29th, 1988 might be shown as 1988059 as a
Seven-Digit Julian Date, and as 8059 for a Four-Digit Julian
Date.

GAO even puts out a clever little form that supply types often
refer to when they can't find their desk calendars.  Made of
heavy card-stock, it is called a "Perpetual Julian Date
Calendar".  There are basically only two types of Julian Date
Calendars, one for Leap Years and one for Non-Leap Years.  The
hassle I had was that in the field we usually didn't have our
desk calendars, and sometimes (usually) couldn't find our GAO
cheat sheets.  Since no well-equipped modern fighting force would
dream of trying to operate without its computer(s), I added the
capability to produce 3-Digit Julian Date calendars as well in
decimal, hexadecimal, and octal numbering systems. . .  If you
don't ordinarily take your computer(s) to the field, you have
the option of printing them out on paper.

I guess it had to happen.  If you solicit suggestions for
enhancement, bug reports, and sound as if you are sincere,
someone may take you up on it.  I received a Fido Message from
Jim Gibbs of KIVY AM/FM in Crockett, TX.  suggesting that maybe
I could modify it to do a "Broadcast" or "Advertising" calendar.
Seems like all of the months in those industries begin on a
Sunday.  If I only had a sample. . .   (Now I do!)  If I only had
a little more time. . .  Actually, the Weekly schedule has the
ability to begin on any day of the week. . .

Another Fido E-Mail message suggested that it would be nice if
it would make Annual, Monthly, and Weekly calendars.  I got to
thinking about that and decided that the Weekly and Daily
Schedules would be helpful for time management, and that perhaps
a monthly calendar would be pretty easy to do too.  I guess that
most businesses have stopped giving them out at Christmas
lately.  So, the ability to do Monthly calendars and Weekly and
Daily schedules was added.  I decided that the schedules should
be allowed to start on any given day, as some people like to
start their weeks on Tuesday, or Thursday.  This will probably
help in the Broadcast or Advertising week thing, as you may
specify that the schedules will start on a Monday.  (More later
for you, Jim. . . )  Chris Lang suggested that the ability to
add user-specified title lines would be helpful, so that he could
make his very own "Wildlife and Fisheries Science Department"
"Monthly Vehicle Use Projection" type calendars.  I pointed out
that he could simply edit the files that it could produce, but
he said that I didn't have to put up with the whining of his
office staff.  I quickly added that capability as well.  In fact,
this capability has been implemented to almost the ridiculous, as
there are now five (5) each user-definable title lines that may be
set at will by the user.  (8 January 1988)

Several people requested that the optional availability of a 12-hour
time format rather than the default 24-hour format would make the
program more useful.  This has now been implemented, although my
initial response was that people should learn to use the 24 hour
time format.  (11 January 1989)

Someone wanted it to do a Hebrew calendar, someone (else) an
Islamic calendar (for equal time); a Lunar calendar, a Mayan
calendar, a Babylonian calendar, . . .  I intend to contact
the local neighborhood rabbi, (I know, things I should have
learned in Schul).  I am even interested in a rumoured scheme
for a thirteen-month calendar. . .  I had never realised how
many ways there are for abstracting the same natural phenomenon
(turn, turn, turn. . .).  (Let's hear it for them Byrd-brains!).

I am no longer certain that there is any way to count the number
of unique calendars that this program can produce.  There are now 33
languages, three numbering systems, two types of time, three different
types of schedules, three different calendars, and a truly infinite
number of personalised ways to make those things.  It can produce
calendars for over 2400 different years, and the schedules can have
5 different user-defined titles.

Why not have the first screen ask which language to use in all
supported languages? Then you could have instructions and
prompts written in whatever language was selected. . .  Alas,
I am not up to that linguistically.  Would need a little help
from all of you out there in the world. . .  And that would
make the program grow somewhat. . .  (Jiminy!!  It's already up
to 26 Kbytes, and runs slightly slower than it used to. . .).
Would you believe 30 Kbytes now, with an automatic 717 byte
weight gain when a virgin copy is run?  Some of that bulkiness
is due to changing to Borland's v1.5, and some is due to putting
back in certain functions that I had gotten rid of.  Some of it may
actually be due to more code and (of course) greater functionality?
(4 Feb 1988)

I do enjoy receiving the platitudes and adulation of a loving user
community.  Warm fuzzies are graciously accepted!!  I received one
letter, however, that suggested that I could not have written both
YEARCAL and this accompanying history file.  I assure all of you
that I am guilty of actually authoring both. . .

I have moved it to Borland's Turbo-C v2.00, and it now weighs
33,450 bytes (34,178 after first execution).  Most of this
increase came about because I added several more languages
(Cantonese, Gaelic, Irish, Japanese, and Turkish).
(7 Jan 1989)

Alan Holub writes a delightful column called "c chest" in Dr. Dobbs'
Journal of Software Tools (formerly known as "Doctor Dobbs' Journal
of Computer Calisthenics and Orthodontia, or Running Light without
Overbyte")  (No, it REALLY was!!  This is a Walt Disney True-life
Adventure. . .)   In the February 1988 edition (#136), Alan suggests
a method of keeping changeable or user configurable parameters
right at the end of the MSDOS .EXE file.  This means a method of
retaining user-set configurations without a separate configuration
file (as I had done in the past).  Those darn things always seem to
get lost in the great bit bucket in the sky, or something that goes
bump in the night munches them into teeny riney bits, or they get lost
on a path of their own. . .  I had worked on a similar thingy, but
gotten trapped by DOS's need for some sort of check-sum.  Alan was
kind enough to show the way, so I have included his routines here.
The bad news is that this technique may not really be portable, as it
is (probably) MSDOS-specific.

The net effect is that you may now set the parameters as you like
them, and then save them as you exit.  They will be waiting for you
the next time!!  This includes the five lines of user installable
titles as well.  There is one little tiny bizarreness about it all,
though.  If you compile the program or run a virgin copy, it will grow
by around 700 bytes when you save your parameters as defaults.  The
Date and Time will also change to the date and time that YOU saved it.
You will need to get the date and version from the sign-on screen.
However, you can set up your very own personally customized version,
now.  (4 February 1988)

In the realm of a more subtle change, the left margin offset may
now be user customized in the various schedules so that you may
really have a binder edge at 20 CPI.  The older versions had been
stuck at an arbitrary seven (7) spaces, which becomes smaller than
desirable when used on an Epson in the 20CPI condensed elite mode.
(4 February 1988)

Lately I have been dreaming about a "Random" calendar.  As I
envision it, the months would be scrambled, and the days of the
week would be scrambled randomly, but have the right dates under
them. . .  How many possible permutations. . .

Here is YEARCAL.  Enjoy it, and remember, the AGGIE calendar
really does have a useful purpose.  I use it to help schedule
meetings of the type of "First Tuesday Monthly" and that sort of
thing.  The code is over-commented by most 'c' programmer's
standards.  I do that so that I can fix it easily three months
later.  Plus, my mother was frightened by an assembler while
carrying me.  By special request, for those purists out there, I
can supply a version of the source that is devoid of white space
that has all variable names shortened to two upper/lower case
characters.

There are some really cute functions there that may be useful
for learning tools.  For example, I know of no way to more
efficiently determine whether or not a year is leap year than
the cute little sieve that I wrote.  (Sin of pride).

By the way, the good news is that:

The Unix System V version is due out "Real Soon Now". . . according to
Ed Braaten, who writes some very good code.  BTW, UPS charges
$22.00 US to send a two-day packet to W.Germany, while the US Snail
only charged $3.23 for Air-Snail service of same package.

The CP/M version is due out "Real Soon Now". . . according to
Jerry P., who writes a lot of very good fiction.

/***************************************************************/

Limitations:

1) Date must be after 1582 and before 4000.  I understand that
   there will be an adjustment of some kind in 4000, but am not
   sure what it is to be.  Act now!!  Write your congressperson!!
   The apathy is deafening. . . Anyway, it will be after my shift. . .

2) Yearcal does not uncorrect for the eleven (ten) day anomaly that
   was corrected by Pope Gregory XIII in 1580.  It is limited
   to year 4000 because the current calendar will have gained
   a day by the year 4316.  A correction obviously MUST be made,
   but all of those that I asked about this seemed not to really
   care.  Fight apathy!!  Write your congressperson!!

3) Assumes 80 column screen, and uses the DOS calls to do screen
   I/O, thus there is no colour, no graphics, and it is s l o w.
   However, it will therefor work on almost all MSDOS machines.

4) Assumes MSDOS for date/time interrupt 21 call to get the DOS
   date.  Source code should port easily to any c compiler, for
   CP/M machines, VAXen, and other dinosaurs. . .

5) It assumes a printer that can print at least 80 columns.  The
   scheduling options for Monthly, Weekly, and Daily schedules
   will ask for the printer page length and width values, and the
   number of spaces for left margin offset, and adjust the output
   accordingly.

6) It assumes that the printer can respond to a form-feed character.

7) It does not do any neat double-wide, emphasized print, nor
   does it make use of any graphics characters.  It just puts out
   vanilla ASCII text.  To do so would be to try to figure out all
   of the many printer codes and do an installation program or
   another menu or something.  IBM Line Drawing Characters are now
   supported, for printers that can print them.

8) It does not work from a command line.  It is interactive.

/***************************************************************/
**  Copyright (c) 1987, 1988, 1989 by Paul M. Sittler.
**  All rights reserved.  The copyright owner hereby authorizes the no-charge,
**  noncommercial making and/or distribution of copies of the entirety of
**  this work unchanged and unincorporated in any other work (except "LiBRary",
**  ".LZH", ".ZIP", or "ARChive" disk files for the sole purpose of
**  no-charge noncommercial distribution).  No other reproduction or use
**  is authorized without the express prior written consent of the
**  copyright owner.

**  Once upon a time, in a kingdom far away, people shared source code and
**  many of us benefited from the sharing.  This silly little program is here
**  presented with source in hopes that it may stimulate the renewed sharing
**  of our efforts.

**  I am open to comment, suggestions for enhancements, and bug
**  reports.

**  Paul M. Sittler
**  1106 Berkeley Drive
**  College Station, TX 77840

**  Modem [phone] 300/1200/2400/9600(HST) baud 24 hours/day
**  My Word #2 Fido 117/1
**  GENie User mail address P.M.SITTLER
**  Also on CompuServe
/***************************************************************/